Rails_security Restful Authentication

Comments and changes to this ticket

• 

  mrflip August 18th, 2008 @ 08:55 AM

  • State changed from “new” to “open”
  • Tag set to “bug, ie, windows”

  Hmm -- I am going to be of little help debugging this since I am a mac weenie. You may want to see if you can recruit another windows user from the #rails IRC channel or railsforum.

  What server is your code running on? Does it fail if you have your code on a remote (non-windows) machine and use IE?

  Even if rest_auth somehow decided to ask IE for http basic, I don't understand why that username and password would fail. the http basic code just checks that same username/password against the DB.

• 

  mrflip August 18th, 2008 @ 09:00 AM

  Lemme expand on the above:

  • I don't understand why it's asking for basic auth in the first place. This is supposed to be governed by the http request somehow. See if you can look at the request and figure out why rails is being fooled.

  • Also it should bounce you to try the password first. Trace through the login_by session, cookie and password paths and see why all fail?

  • Finally: why, once it has decided to ask for http basic auth, does that username and password fail?

  • Are you sure it's asking for http basic auth and not some crazy windows thing?

• You flagged this item as spam.
  

  Brian Evans August 18th, 2008 @ 09:46 AM

  thanks for the suggestions, I will do some more testing and see what I can find out.

  I work on a mac most of the time, and everything worked fine until it went live and the client couldn't login. That's when I found out it is an IE bug.

  Is there any way to disable http basic and see what happens then?

  I'll still check everything else and get back with you.

• You flagged this item as spam.
  

  Brian Evans August 18th, 2008 @ 09:48 AM

  Another thing I noticed, is that if I go to domain.com/admin (which has the before_filter on it), I get the login screen, doesn't redirect me to the login script. If I go directly to domain.com/session/new, the login screen comes up and everything works fine, I can login and access everything.

  BTW, it is hosted on hostingrails.com, so it isn't hosted on a windows environment.

• You flagged this item as spam.
  

  Brian Evans August 18th, 2008 @ 10:02 AM

  Also, here is what is logged in the production.log. I am not sure what "filter chain halted" means:

  Processing DashboardController#index (for XX.XX.XX.XX at 2008-08-18 09:50:30) [GET] Session ID: BAh7BzoMY3NyZl9pZCIlZWEzZGNmOWUzZTJkOGMwNDM2MmNiNGM3N2JjZTVl YTYiCmZsYXNoSUM6J0FjdGlvbkNvbnRyb2xsZXI6OkZsYXNoOjpGbGFzaEhh c2h7AAY6CkB1c2VkewA=--2c2e19bd4de161431e7550b22033bb4e9f187b1a Parameters: {"action"=>"index", "controller"=>"dashboard"} Filter chain halted as [:login_required] rendered_or_redirected. Completed in 0.00071 (1404 reqs/sec) | Rendering: 0.00007 (10%) | DB: 0.00000 (0%) | 401 Unauthorized [http://www.domain.com/siteadmin/...]

• You flagged this item as spam.
  

  Brian Evans August 18th, 2008 @ 10:05 AM

  This is what happens when I use FireFox and access the same page - and it works - redirects me to the login page (even on windows):

  Processing SessionsController#new (for XX.XX.XX.XX at 2008-08-18 10:04:01) [GET] Session ID: BAh7BzoOcmV0dXJuX3RvIhcvc2l0ZWFkbWluL3B1YmxpYy8iCmZsYXNoSUM6 J0FjdGlvbkNvbnRyb2xsZXI6OkZsYXNoOjpGbGFzaEhhc2h7AAY6CkB1c2Vk ewA=--627a7cb3ff7fcb8f63c8bcc778510f04357e4e77 Parameters: {"action"=>"new", "controller"=>"sessions"} Rendering template within layouts/login Rendering sessions/new Completed in 0.00119 (841 reqs/sec) | Rendering: 0.00107 (90%) | DB: 0.00000 (0%) | 200 OK [http://www.domain.com/siteadmin/...]

• 

  mrflip August 18th, 2008 @ 10:44 AM

  I think filter_chain halted just refers to the before_filter that enforces logins.

  I'm now mostly wondering if something different in the HTTP request is fooling rails into asking for HTTP auth.

  It falls thru to HTTP auth in lib/authenticated_system.rb:

  
      # Redirect as appropriate when an access request fails.
      #
      # The default action is to redirect to the login screen.
      #
      # Override this method in your controllers if you want to have special
      # behavior in case the <%= file_name %> is not authorized
      # to access the requested action.  For example, a popup window might
      # simply close itself.
      def access_denied
        respond_to do |format|
          format.html do
            store_location
            redirect_to new_<%= controller_routing_name %>_path
          end
          # format.any doesn't work in rails version < http://dev.rubyonrails.org/changeset/8987
          # you may want to change format.any to e.g. format.any(:js, :xml)
          format.any do
            request_http_basic_authentication 'Web Password'
          end
        end
      end
  

  Try tracing through that method and see why it makes the decision it does. Can you dump the request and see if anything is obvs. different? (dump with logger.error, or turn down the log threshold

  If you don't care about having HTTP auth for bot API access, you could try (code untested, YMMV) this to disable it:

  
      def access_denied
        store_location
        redirect_to new_<%= controller_routing_name %>_path
      end
  

• 

  mrflip August 18th, 2008 @ 10:46 AM

  Assuming it takes the wrong path thru that method, BTW, the thing to look at (as far as I know) is stuff like the MIME type of the request and the 'accepts' header.

  Just to check: what version of Rails? And you are using the latest version of restful-authentication -- last commit was "merging from nbibler"?

• You flagged this item as spam.
  

  Greg Sterndale September 4th, 2008 @ 10:46 PM

  • Assigned user cleared.

  I'm having the exact same problem.

  This may help...

  http://github.com/technoweenie/r...

  I tried adding the following line to access_denied to no avail:

  def access_denied

    request.format ||= :html if request.env['HTTP_USER_AGENT'] =~ /msie/i
    ...
  
  

  end

  Let me know if you find/found a solution.

• 

  mrflip September 4th, 2008 @ 11:01 PM

  What is the value of request.format with IE, with Mozilla, etc? From the comments there IE sends the wrong thing, which is to say it sends something, and so the request.format ||= :html will never act. Can you instead try

  
  def access_denied
    request.format = :html if request.env['HTTP_USER_AGENT'] =~ /msie/i
    ...
  end
  

  There is also this, added earlier this year: http://dev.rubyonrails.org/ticke... I have no idea if it's related but that section of code is where I'd start digging.

• You flagged this item as spam.
  

  Greg Sterndale September 4th, 2008 @ 11:28 PM

  Thanks mrflip.

  That's exactly where I ended up.

  Another helpful link: http://geminstallthat.wordpress....

• You flagged this item as spam.
  

  alexandre (at bubble.com) September 8th, 2008 @ 07:26 PM

  I'm having the exact same problem but in this case with firefox 1.5!

  I've got a small sample app running rails 2.1 and the latest release of RA.When i go to the controller that has the before_filter call,it gives me the authentication windows instead of the regular html form.It onyl happens in firefox,goes perfectly fine on safari.I noticed that started happening after I upgraded from rails 2.0 to 2.1,so this my help you guys somehow.

• You flagged this item as spam.
  

  Paul Gallagher September 23rd, 2008 @ 07:57 AM

  • Tag changed from “bug, ie, windows” to “bug, ie, windows”

  @mrflip, I think you can actually blame this on a subtle behaviour of MimeResponds!

  As far as I can see, the problem is that if I use format.any in a responds_to block, it will always catch unless the other format options (like format.html) are specifically preferred by the browser (i.e. included in the HTTP_ACCEPTS header)

  So using format.html/format.any is fine, as long as the browser includes text/html in the accepts header.

  IE6 doesn't (and also FF1.5 according to alexendre), but that's not because its broken. According to the HTTP RFC there's no compulsion to list the specific formats you accept.

  I reckon the proper fix to this is in MimeResponds, but until then I suggest the best thing for restful_authentication would be to qualify the format.any by default.

  
    def access_denied
      respond_to do |format|
        format.html do
          store_location
          redirect_to new_session_path
        end
        format.any(:js, :xml) do
          request_http_basic_authentication 'Web Password'
        end
      end
    end
  

  This works well for me in IE and FF without resorting to browser-specific tricks, and if HTTP Auth needs to be invoked by the developer for other situations, they can override as desired.

• You flagged this item as spam.
  

  Paul Gallagher September 23rd, 2008 @ 07:57 AM

  @mrflip, I think you can actually blame this on a subtle behaviour of MimeResponds!

  As far as I can see, the problem is that if I use format.any in a responds_to block, it will always catch unless the other format options (like format.html) are specifically preferred by the browser (i.e. included in the HTTP_ACCEPTS header)

  So using format.html/format.any is fine, as long as the browser includes text/html in the accepts header.

  IE6 doesn't (and also FF1.5 according to alexendre), but that's not because its broken. According to the HTTP RFC there's no compulsion to list the specific formats you accept.

  I reckon the proper fix to this is in MimeResponds, but until then I suggest the best thing for restful_authentication would be to qualify the format.any by default.

  
    def access_denied
      respond_to do |format|
        format.html do
          store_location
          redirect_to new_session_path
        end
        format.any(:js, :xml) do
          request_http_basic_authentication 'Web Password'
        end
      end
    end
  

  This works well for me in IE and FF without resorting to browser-specific tricks, and if HTTP Auth needs to be invoked by the developer for other situations, they can override as desired.